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REMARKS 

By this amendment, claims 1-37 are pending, in which claims 1, 8, 9, 15, 16, 22, 29 and 
36 are currently amended. No new matter is introduced. 

The Office Action mailed December 7, 2005 rejected claims 1-4, 8-11, 15-18, 22-25, 29- 
32 and 36-37 as obvious under 35 U.S.C. § 103 based on Kitchen et al (US 6,289,322) in view 
of McNair (US Pat. Pub. No. 2001/0037297 Al), claims 5, 12, 19, 26 and 33 as obvious based 
on Kitchen et al in view of McNair and further in view of "Pay and Save" (Nicos Michaelas et 
al, June 1999), claims 6, 13, 20, 27 and 34 as obvious based on Kitchen et al in view of McNair 
and further in view of "E-forms Learn New Language" (H. Hayes, Feb. 2000), and claims 7, 14, 
21, 28 and 35 as obvious based on Kitchen et al, McNair, E-forms and further in view of Boesch 
et al (US 5,870,473). 

Applicant respectfully traverses the obviousness rejections as the applied art, alone or in 
combination, fails to teach or make obvious the claimed features. 

Independent claims 1, 8, 15 and 29 recite "determining whether the invoice amount is a 
zero balance or a credit balance; and selectively terminating the payment and generating a 
disallow payment message based upon the determining step." Claim 22 recites "means for 
determining whether the invoice amount is a zero balance or a credit balance; and means for 
selectively terminating the payment and generating a disallow payment message based upon 
the determination." Claim 36 recites "a mechanism for determining whether the total invoice 
amount is a zero balance or credit balance prior to executing the electronic payment, wherein 
in response to determination of the zero or credit balance, the mechanism terminating the 
payment mechanism and generating a disallow payment message for display to the customer." 
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For a supposed teaching of the above features, the Office Action relies on the secondary 
reference of McNair, after acknowledging that such features are absent from Kitchen et al (page 
2). Specifically, the Office Action, on page 3, refers to FIGs. 1, 2 and 4 and paragraphs [0048], 
[0055], and [0056] of McNair. FIGs. 1 and 2 merely show a procedure for generating a bill. The 
only information of relevance appears to be the financial activities of Previous Balance 27 and 
Payments and Credits 23 (FIG. 1), which are printed on the bill 46 (FIG. 2). One of ordinary 
skill in the art would not reasonably conclude, based on these diagrams and associated text, that 
the claimed features are disclosed. McNair, in the following passages (encompassing the cited 
passages), states (Emphasis Added): 

[0048] A CPU 13 (central processing unit) of the payee accumulates an account 
information 14. Account information 14 is comprised of the payer's account 
number 16 with the payee and phone number 21 of the payee. CPU 13 also 
accumulates the payer's recent financial activity 22 up to the statement closing 
date 24. Activity 22 is comprised of new purchases 25, finance charges 26, new 
balance 28, and time bounding such as closing date 24 and payment due date 30. 
CPU 13 processes instructions to a word processor 32, which formats and sends 
them to an alphanumeric printer 34. Processor 32 causes printer 34 to print 
account information 14 and activity 22 on a sheet of paper 36 as alphanumeric 
information 38. CPU 13 is also programmed to encode the data into a barcode 
processing instruction 40. Generally, barcode printers have the ability to encode 
data into barcode images. If printer 34 is limited to alphanumerical characters, 
then processing instruction 40 causes a barcode printer 44 to add symbol 42 in the 
top margin of the paper 36. If printer 34, for example a laser printer, has the 
ability to print characters other than alphanumerical, CPU 13 will encode 
information 14 and activity 22 into processing instruction 40a. Command 41 
causes printer 34 to print account information 14 and activity 22 as a symbol 42 in 
the top margin of the paper 36. 

[0054] A control instructions editor 54 has been installed in PC 52. Editor 54 
processes signal 50. Editor 54 is programmed to determine if access code 13 is 
present in signal 50. If access code 13 is present in signal 50, editor 54 will 
automatically integrate account information 14 and activity 22 into editor 54. 
Editor 54 enables the payer to interface with image 60 utilizing user data 
entry such as a mouse 66 and a keyboard 67. Image 60 follows the same format 
of alphanumeric information 38 so that the payer can easily compare image 60 
with account information 14 and activity 22 to feel comfortable using editor 54 for 
payment transaction instructions. 
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[0055] A "NEXT" button 64 is located on the lower right corner of image 60. 
Clicking "NEXT" button 64 with mouse 66 causes a transaction display 68 to 
appear on terminal 62 as shown in FIG. 7. Since the payee allows installment 
payments, the payee offers the payer choices of clicking a button 70 labeled "Pay 
(minimum) amount of $54.43", a button 72 labeled "Pay (intermediate amount) 
$_ . ", or a button 74 labeled "Pay new balance of $1,187.46". 

[0056] Editor 54 polices for input errors. Buttons 70, 72, and 74 are mutually 
exclusive and mouse 66 must click one of them. If mouse 66 clicks button 72, an 
amount between $54.43 and $1,187.46 must be entered in the blank space prior to 
proceeding further. If "NEXT" button 64 is clicked without transaction 
display 68 being properly filled out, a conventional error message (not 
shown) will appear. The payer has clicked button 72 to pay the intermediate 
amount of $200.00 by and using keyboard 67 to enter 200.00 in the space 
provided. 



Firstly, these passages make no mention "determining whether the invoice amount is a 
zero balance or a credit balance," as McNair only describes that Previous Balance 27 and 
Payments and Credits 23 are display without any need to determine the value of such balance and 
credits to "generating a disallow payment message." 

Secondly, the above passages simply describe the capability of the editor 54, as an 
interface for the payer, to generate a "conventional error message" for input errors; such errors 
stem from clicking the "NEXT" button without entering the proper input. The Office Action 
appears to equate the claimed feature of "generating a disallow payment message" to this 
conventional error message of the McNair system. However, the McNair system's error message 
is not a "disallow payment" message, in that the error message pertains to an input error - i.e., 
the conventional error message is triggered when the transaction display 68 is not properly filled 
out. Such error message has no relevance to disallowing payment. 

The Examiner is reminded that 35 U.S.C. § 132 requires the Director to "notify the 
applicant thereof, stating the reasons for such rejection." This section is violated if the rejection 
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"is so uninformative that it prevents the applicant from recognizing and seeking to counter the 
grounds for rejection." Chester v. Miller, 15 USPQ2d 1333 (Fed. Cir. 1990). Unfortunately, the 
Examiner's only discussion of the subject claimed features are vague references to seemingly 
irrelevant passages (FIGs. 1, 2 and 4 and paragraphs [0048], [0055], and [0056]). 

Even assuming the references were properly combined based on some teaching or 
suggestion in the references, and assuming the modifications proposed in the Office Action were 
justified by additional teachings or suggestions found in the references, even the combination 
does not render the claimed invention obvious. Specifically, none the references taken alone, or 
in combination, teaches or suggests "determining whether the invoice amount is a zero balance 
or a credit balance; and selectively terminating the payment and generating a disallow 
payment message based upon the determining step." Therefore, Applicant respectfully submits 
that the features of independent claims 1, 8, 15, 22, 29 and 36 are not satisfied. 

The rejection of dependent claims 2, 3, 9-11, 16-18, 23-25, 30-32, and 37 should likewise 
be withdrawn for at least the reasons put forth for the allowability of their respective independent 
claims. Additionally, these claims are also patentable on their own merits. For example, claim 2 
recites "wherein the determining step comprises: applying business rules in real-time." The 
Office Action (page 4) cites to paragraphs [0055] and [0056]. However, close study of these 
passages reveal no discussion of "business rules," much less in the context of the claim. 

Further, the secondary references of Pay and Save, E-forms, and Boesch et al. do not fill 
in the gaps of Kitchen et al and McNair. Pay and Save was applied for a supposed teaching of 
"calculating a discount for early payment of an invoice." E-forms was relied upon for a supposed 
disclosure of "generating an HTML invoice." Lastly, Boesch et al. was applied for a supposed 
teaching of "generating a severity code associated with the billing error." Accordingly, the 
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obviousness rejections of claims 5, 12, 19, 26 and 33 over the combination of Kitchen et al, 
McNair and Pay and Save; claims 6, 13, 20, 27 and 34 over Kitchen et al, McNair and E-forms, 
and claims 7, 14, 21, 28 and 35 in view of Boesch et al are overcome, as a prima facie case of 
obviousness has not been established. 

Therefore, the present application, as amended, overcomes the rejections of record and is 
in condition for allowance. Favorable consideration is respectfully requested. If any unresolved 
issues remain, it is respectfully requested that the Examiner telephone the undersigned attorney at 
(703) 425-8508 so that such issues may be resolved as expeditiously as possible. 



10507 Braddock Road 
Suite A 

Fairfax, VA 22032 
Tel. (703) 425-8508 
Fax. (703) 425-8518 



Respectfully Submitted, 



DITTHAVONG & MORI, P.C. 





Attorney/Agent for Applicant(s) 
Reg. No. 44658 
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